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The ability to successfully perform rendezvous has been the cornerstone of US 
manned space exploration since its inception. And at the heart of the execution of 
rendezvous has been ability to perform relative navigation with respect to the 
target. Over these many decades, as computer and sensor technology have 
advanced, the function of relative navigation has both become easier and become 
more challenging. Better computational resources are not imposing the harsh 
demands on precision as they were thirty years ago. At the same time, sensors 
provide a great deal more information in terms of images and this means that 
computational resources are in increased demand with respect to image processing. 
Any relative navigation system designed today makes use of sensors such as Lidars, 
imaging star trackers all of which provide relative navigation but require processing 
throughput, though many of these sensors do their own processing internally. 

The Orion relative Navigation System has sought to take advantage of the latest 
developments in sensor and algorithm technology while living under the constraints 
of mass, power, volume, and throughput. In particular, the only sensor specifically 
designed for relative navigation is the Vision Navigation System (VNS), a lidar-based 
sensor. But it uses the Star Trackers, GPS (when available) and IMUs, which are part 
of the overall Orion navigation sensor suite, to produce a relative state accurate 
enough to dock with the ISS. 

The Orion Relative Navigation System has significantly matured as the program has 
evolved from the design phase to the flight software implementation phase. With 
the development of the VNS system and the STORRM flight test of the Orion Relative 
Navigation hardware, much of the performance of the system will be characterized 
before the first flight. However challenges abound, not the least of which is the 
elimination of the RF range and range-rate system, along with the development of 
the FSW in the Matlab/Simulink/Stateflow environment. This paper will address 
the features and the rationale for the Orion Relative Navigation design as well as the 
performance of the FSW in a 6-DOF environment as well as the initial results of the 
hardware performance from the STORRM flight. 

Whereas, the first missions of Orion are being planned to the ISS, the relative 
navigation system makes no assumptions as to the central body of the rendezvous. 

In particular, it has been designed to also operate outside of LEO. As such, it is not 
reliant on the GPS constellation for its accuracy. 

The Orion Relative Navigation System is designed to operate from when the two 
vehicles are more than 300 km away from each other to all the way to dock. As such 
the system incorporates various kinds of measurements, from ground updates, to 
star tracker angle measurements to LIDAR measurements (range, bearing). As one 
might expect, IMU measurements are used to propagate states when no relative 



measurements are available. Additionally, Orion GPS measurements, when 
available, are used but only the PVT is used. This was done to simplify the relative 
navigation design, and to occasionally anchor the inertial translation states 

The dual-inertial state filter that is used is flexible enough that accurate inertial 
states are not crucial. In fact, in LEO, GPS measurements are inhibited during the 
prox-ops phase; hence the inertial states may drift but the relative states remain 
accurate because of the accuracy of the LIDAR system. Many of the challenges 
involve the ability of the system to handle latent measurements. A high-order 
gravity field is used to propagate both the target and Orion states. Because it is 
design to operate all the way to dock, both relative translation states and relative 
attitude states are necessary. Two different filters, a relative translation filter 
(RTFILT) and a relative attitude filter (RAFILT) have been designed and 
implemented. 

The translation relative navigation filter (RTFILT) operates at 1 Hz, using buffered 
IMU data. The relative attitude filter (RAFILT) operates at 5 Hz. But this filter 
(RAFILT) only operates during the final 20 meters of the rendezvous/proxops 
phase. 

In the earlier phase of the design, Linear Covariance analysis was used to evaluate 
the performance of the relative navigation system design. This methodology 
allowed sensitivity analyses to be done and allowed trade studies to be quickly 
performed. As the design has matured, the design has been implemented the 
Matlab/Simulink environment, primarily in eML, as part of the flight software 
process. As part of this exercise, some of the metrics like cyclomatic complexity, 
have spurred improvements to make the algorithms more efficient, both in terms of 
SLOCs and in terms of arithmetic operations (multiplies/divides, adds/subtracts). 
These improvements have resulted in more efficient flight code. 

Monte Carlo analysis is now being used to evaluate not only the relative navigation 
performance but also the overall rendezvous performance. Thus, the guidance, 
navigation and control functions are exercised to provide the overall system 
performance. 

This paper will discuss the design of the Orion Relative Navigation system as well as 
present the Monte Carlo results that will demonstrate its performance. 



